Gui-based wallet program for online transactions

ABSTRACT

Provided is a method and a GUI-based software application that acts as a wallet with network interconnectivity for enabling a user to securely and seamlessly conduct transactions with his or her online financial transaction program by means of a computer or a wireless handheld device without having to depend on an Internet browser.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. application Ser.No. 12/237,060, which was filed on Sep. 24, 2008, the entire disclosureof which is incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to online, Internet-based financialtransaction programs and commercial systems and more particularly toconducting online financial transactions with an Internet browserindependent software application.

BACKGROUND OF THE INVENTION

With the advent of the Internet and online electronic commerce(e-commerce), financial transaction programs that allow users toseamlessly purchase products, transfer funds and conduct transactionsover an Internet connection have been in high demand.

Traditional methods of executing financial transactions have beenlimited to a user providing his or her credit card, debit card, orchecking account number on a commercial website, or using checks, moneyorders and other forms of paper-based payments. However, these means ofexecuting financial transactions are often cumbersome, slow, andinconvenient, requiring a user to remember a multitude of accountnumbers, login data and passwords. This often results in significanttime delays for payment processing. Furthermore, security and fraudconcerns are prevalent. For instance, a user is often reluctant toprovide sensitive credit card or debit card information over an Internetconnection, regardless of how “secure” an Internet connection claims tobe.

Recent financial transaction programs have emerged as a means for a userto pay for purchases, transfer money, receive money (if the user is amerchant), store shipping addresses, and set up multiple financialaccounts (e.g. checking or savings, credit card, debit card) all withone single login and password. Security and fraud concerns are alsomitigated by means of online financial security precautions, encryptionmethods, and anti-phising programs that are inherent in online,Internet-based financial transaction systems.

However, many of these financial transaction programs are limited inthat users are dependent on an Internet browser in order to browse to amain website, enter their username and password data and access theiraccount information in order to execute financial transactions such aspaying for purchases, transferring money or checking account balances.

Users are limited in that they are dependent on a computer with Internetaccess and an Internet browser, or a wireless handheld device (e.g. cellphone, BlackBerry, PDA) with an Internet browser application installed.Problems arise if the Internet browser is broken. In that case, the userhas no other means of accessing his or her online financial transactionprogram website. Furthermore, the level of user convenience for a givenInternet browsing experience is limited to the specifications of theInternet browser. In other words, the user is stuck with thehard-to-locate buttons, keys or pull-down menus of a selected Internetbrowser, when the ideal alternative is a user-friendly Graphic UserInterface (GUI) program with intuitive aesthetics and keys/buttonsplaced in regions optimal for user convenience.

Therefore, there is need for a method or software application with auser-friendly GUI setup that enables a user to access their onlinefinancial transaction program account without having to depend on anInternet browser. One such browser-independent solution is the use of asoftware application known as a “Widget”, previously known as“Konfabulator”. Widgets are basically software applications that use aJavaScript runtime environment coupled with an XML interpreter readingXML code to run miniature browser-independent GUI applications. Widgetsalso usually feature a flexible Application Programming Interface (API)for users and programmers to make their own Widgets. Typical Widgetsinclude: weather forecast monitors, temperature or climate indicators,digital clocks, day planners, calendars, stock-tickers, sports gamescoreboards, calculators and currency converters.

However, the one common feature shared by all Widgets is that they areall “passive” monitors, displayers or calculators of information. Forinstance, you only use a Widget to observe the weather, tell the time,convert currency rates, or be informed about the present status of astock or the current score of a sports game. No Widget allows for directinteraction with the external world. For instance, a user cannot use aWidget to conduct financial transactions that have an actual impact onhis or her bank account, which belongs in the physical external world.In other words, a user cannot use a Widget to transfer money fromhis/her bank account, withdraw funds, pay for bills, or perform otherfinancial transactions that have an impact on the world outside of theuser's computer.

Therefore, there is a need in the art for an Internet browserindependent software application similar to Widget-based technology butwhich integrates a network-interconnectivity aspect and which alsoutilizes a user-friendly GUI configuration in order to allow a user toseamlessly and securely conduct financial transactions online with acomputer or wireless handheld device without having to depend on anInternet browser.

SUMMARY OF THE INVENTION

Provided is a method and a GUI-based software application that acts as awallet (“GUI Wallet”) with network interconnectivity for enabling a userto securely and seamlessly conduct transactions with his or her onlinefinancial transaction program by means of a computer or a wirelesshandheld device without having to depend on an Internet browser.

First, the user opens the GUI Wallet and then inputs login informationsuch as a username and a password. Then, a communication engine on thewidget communicates the login information to the communication engine onthe server of an online financial transaction program to see if thelogin information is valid by looking up relevant login information froma database If the login information is valid, then the server pulls upthe user's relevant financial information. Then, the user is presentedwith a plurality of options in the form of buttons in a GUI Wallet.

On a first tab of the GUI Wallet, the user is presented with a pluralityof buttons representing different funding sources (Cash/Checks, Visa,Debit Card and Reward Points) and the user's shipping address and otherID data. The user may drag-and-drop any of these buttons into the blankfields of a merchant's website, and the Wallet program then populatesthe fields with the relevant information (credit card number, shippingaddress, etc.).

On a second tab of the GUI Wallet, the user is presented with aplurality of buttons representing different types of transactions thatcan be performed with an online financial transaction program. Thesebuttons may comprise transferring money, accepting payments ortransfers, checking balances of accounts, paying for bills andconverting currencies. Since the user has already logged in, all therelevant user ID and financial information is stored and ready for use.This enables a convenient means of performing financial transactionswithout having to re-enter login information and without having to relyon an Internet browser.

The GUI Wallet uses a communication engine to communicate with anothercommunication engine located on the server of the online financialtransaction program. The GUI Wallet sends encrypted data to the server'scommunication engine, which decrypts it. Then, the decrypted data issent to an integration engine of the server, which interfaces with aplurality of databases to perform validation, complete transactions andcheck security. The databases store information such as login ID data,user financial data, blacklists of unsafe websites, reward point totalsand transaction histories. Data sent back from the server to the GUIWallet is also encrypted and then decrypted when received by the GUIWallet.

Merchant sites can also be checked for security. If the site is amerchant site that is known for engaging in phishing or fraud, then theGUI Wallet will alert the user. A blacklist of unsafe sites is stored inone of the databases associated with the server of the online financialtransaction program.

Further limitations and disadvantages of conventional and traditionalapproaches will become apparent to one of skill in the art, throughcomparison of such systems with the present invention as set forth inthe remainder of the present application with reference to the drawings.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a diagram of a GUI Wallet with a first plurality of buttonsaccording to an embodiment of the invention.

FIG. 2 is a diagram showing using the GUI Wallet to drag-and-dropbuttons into empty shipping address or ID fields of a merchant websiteaccording to another embodiment of the invention.

FIG. 3 is a diagram showing using the GUI Wallet to drag-and-dropbuttons into empty payment method fields of a merchant website accordingto another embodiment of the invention.

FIG. 4 is a diagram showing the connection between the communicationengine of the GUI Wallet and the communication engine of a serverassociated with an online financial transaction program according toanother embodiment of the invention.

FIG. 5 is a diagram of a GUI Wallet with a second tab having a secondplurality of buttons according to another embodiment of the invention.

FIG. 6 is a flowchart showing the steps a user takes in using a GUIWallet to conduct transactions according to another embodiment of theinvention.

FIG. 7 is a flowchart showing the steps of how the communication engineof the GUI Wallet and the communication engine of the server send andreceive data, according to another embodiment of the invention.

To allow cross-referencing among the figures, like elements in thefigures are provided like reference numerals.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled inthe art to make and use the invention, and is provided in the context ofparticular applications of the invention. Various modifications to thedisclosed embodiments will be apparent to those skilled in the art andthe general principles defined herein may be applied to otherembodiments and applications without departing from the spirit and scopeof the invention.

According to embodiments of the invention, provided is a method and aGUI-based software “Wallet” application or a “GUI Wallet” with networkinterconnectivity for enabling a user to securely and seamlessly conducttransactions with his or her online financial transaction program bymeans of a computer or a wireless handheld device without having todepend on an Internet browser.

FIG. 1 is a diagram of a GUI Wallet with a first plurality of buttons onone or more tabs according to an embodiment of the invention. The firsttab 100 of the GUI Wallet has a plurality of funding source buttons 105,110, 115, 125, an ID button 120 and an alert button 130. Internal to theGUI Wallet software application is the communication engine W 135 of theGUI Wallet, which may be shown on the GUI interface of the GUI Walletwith some sort of GUI indicator, but is shown here in FIG. 1 as ageneric icon. The plurality of funding source buttons can include, forexample, a cash/check/money-order payment button 105 (“Cash”), a Visa orcredit card payment button 110 (“Visa”), a debit card payment button 115(“DbC”), and a reward point payment button 125 (“RwPt”), as shown inFIG. 1. However, the plurality of funding payment buttons is not limitedto the aforementioned list, and the above list is not exhaustive in anyway. The cash/check/money-order payment button 105 is tied to softwarein the GUI Wallet that stores the information about the payment orfunding source, such as a user's check number, money order number, orthe routing number, account number and name of the account holder of achecking account. The Visa or credit card payment button 110 is tied tosoftware in the GUI Wallet that stores a user's credit card informationsuch as credit card type, credit card number, name of cardholder,expiration date of card, and card security code. The debit card paymentbutton 115 is tied to software in the GUI Wallet that stores a user'sdebit card information, which should be identical to the credit cardinformation described above. Finally, the reward point payment button125 is tied to software in the GUI Wallet that stores promotional codenumbers, gift card or gift certificate numbers, reward point codes orother types of currency used in reward point systems. All the above datahas already been entered by the user before. The drag-and-dropfunctionality of the funding source buttons will be further detailed inthe description of FIG. 3.

The ID button 120 as shown in FIG. 1 stores ID information associatedwith the user. In other embodiments, a plurality of different ID buttonscan be displayed and store different types of ID information associatedwith the user. ID information associated with the user may include, butis not limited to: the user's name (including any titles, departmentdesignators, suffixes, prefixes), the shipping address of the user, thebilling address of the user, contact phone numbers of the user, andemail addresses of the user. The ID button 120 is tied to software inthe GUI Wallet that stores this ID information of the user, which hasalready been entered by the user previously. The drag-and-dropfunctionality of the ID source button 120 will be further detailed inthe description of FIG. 2.

The alert button 130 alerts the user on a single issue as shown inFIG. 1. In other embodiments, a plurality of different alert buttons canbe shown and alert the user on different issues. The list of issues thata user can be alerted on include, but is not limited to: whether amerchant site is “unsafe” or has a previous history of phising or fraud,whether the communication link established between the GUI Wallet and agiven merchant site is secure, whether the user's ID information iscorrect and matches the user's records, whether a given transaction hasbeen completed or has been successful, or whether a given transaction isnot successful. An alert button 130 can also trigger pop-ups or messagewindows alerting the user of the aforementioned issues. The alert button130 is tied to software of the GUI Wallet that alerts the user on theaforementioned list of issues.

The communication engine W 135 is the communication engine of the GUIWallet, hence there is a “W” at the end of its name, to denote “Wallet”.The communication engine W 135 communicates with a communication engineS 415 (“S” to denote “Server”), which is further described in FIG. 4.Even though the communication engine W 135 cannot be usually seen on theactual GUI Wallet and it is optional for the GUI Wallet to have an icondenoting the communication engine W 135, a GUI bar, light or box can bemade to indicate to the user that the GUI Wallet is in the process ofcommunicating with a server 410 (in FIG. 4) of the online financialtransaction program by means of the communication engine W 135. This isalmost like a flashing green “status indicator” light frequently seen onprograms or devices that indicate that the program or device is engagingin a current communication with something else or is currently in a“busy” mode. The functionality of the communication engine W 135 and itsinteraction with the communication engine S 415 of the server 410 of theonline financial transaction program will be further detailed in thedescription of FIG. 4.

FIG. 2 is a diagram showing using the GUI Wallet to drag-and-dropbuttons into empty shipping address or ID fields of a merchant websiteaccording to one embodiment of the invention. A user can drag the IDbutton 120 from the first tab 100 of the GUI Wallet and drop it into aUser ID Page 210 of a merchant website. The User ID Page 210 has aplurality of ID fields 215 (e.g. as shown in FIG. 2: Full Name, AddressLine 1, Address Line 2, City, State/Province/Region, ZIP/Postal Code,Country, Phone Number, and Email). However, the plurality of ID fields215 is not limited to the ID fields shown in FIG. 2 nor are the IDfields shown in FIG. 2 in any way exhaustive. Once the user hasdragged-and-dropped the ID button 120 from the first tab 100 of the GUIWallet to the User ID Page 210, the plurality of ID fields 215 arepopulated with the appropriate data. If the user has already entered IDinformation previously, dragging-and-dropping the ID button 120 from thefirst tab 100 of the GUI Wallet to the User ID Page 210 of the merchantwebsite will result in a pre-entered user ID data 220 showing up on theUser ID Page 210. After the ID information has been entered, the usercan then confirm shipping to this address. The user can repeat a similarprocess for entering a billing address or other IDs if multiple IDbuttons are used. The drag-and-drop functionality of the GUI Wallet isrobust, simple and convenient, because it allows a user to simplydrag-and-drop ID information from a portable GUI Wallet into a merchantwebsite without having to remember a multitude of ID data (accountnumbers) and open up a separate Internet browser.

FIG. 3 is a diagram showing using the GUI Wallet to drag-and-dropbuttons into empty payment method fields of a merchant website accordingto another embodiment of the invention. The first tab 100 of the GUIWallet with the plurality of buttons has a plurality of funding sourcebuttons, which include, as shown in FIG. 1, a cash/check/money-orderpayment button 105, a visa or credit card payment button 110, a debitcard payment button 115, and a reward point payment button 125. A usercan drag any of the aforementioned funding source buttons from the firsttab 100 of the GUI Wallet and drop it into a Payment Method Page 310 ofa merchant website. The Payment Method page 310 has a plurality of entryfields, including, as shown in FIG. 3, credit card or debit card entryfields 315, checking account entry fields 320, check or money orderentry field 325, and reward point entry field 330. However, theplurality of entry fields is not limited to the entry fields as shown inFIG. 3 nor are the entry fields shown in FIG. 3 in any way exhaustive.Also, as described above for FIG. 1, the plurality of funding sourcebuttons are not limited to the funding source buttons shown in FIG. 1and are the list of funding source buttons in FIG. 1 are not in any wayexhaustive.

Once the user has dragged-and-dropped any of the plurality of fundingsource buttons from the first tab 100 of the GUI Wallet to the PaymentMethod Page 310, the respective entry field is populated with theappropriate data. For instance, if the user drags-and-drops thecash/check/money-order payment button 105 from the GUI Wallet to achecking account entry field 320 or a check or money order entry field325, those respective fields will be populated with the appropriate data(e.g. for the checking account entry field 320, the “Routing Number”,“Account Number” and “Name of Account Holder” would be filled in withthe user's data, and for the check or money order number, the fieldwould be filled in with the user's data). Also, if the userdrags-and-drops the Visa or credit card payment button 110 or the debitcard payment button 115 from the GUI Wallet to a credit card or debitcard entry field 315, then the relevant fields would be populated withthe appropriate data (e.g. the “Card Type”, “Credit Card Number”, “Nameof Cardholder”, “Exp. Date of Card” and “CSC (Card Security Code)”).Finally, if the user drags-and-drops the reward point payment button 125from the GUI Wallet to a reward point entry field 330, the field wouldbe filled in with the user's data, e.g. a money order number or checknumber or other identifier. The sub-fields of the above mentioned entryfields (e.g. the “Routing Number”, “Account Number” and “Name of AccountHolder” are all sub-fields of the checking account entry field 320) arenot limited to the sub-fields shown in FIG. 3, and can comprise other ordifferent sub-fields, as appropriate. After the relevant paymentinformation has been entered, the user can then confirm a selectedpayment method. The drag-and-drop functionality of the GUI Wallet issimple, robust and convenient, because it allows a user to simplydrag-and-drop payment method information from a portable GUI Wallet intoa merchant website without having to remember a multitude of ID data(account numbers) and open up a separate Internet browser.

FIG. 4 is a diagram showing the connection between the communicationengine of the GUI Wallet and the communication engine of a serverassociated with an online financial transaction program according toanother embodiment of the invention. The communication engine W 135 ofthe GUI Wallet comprising the first tab 100 shown in FIG. 1 and a secondtab 500 shown in FIG. 5 is coupled to an Internet connection 405 to thecommunication engine S 415 of a server 410 of an online financialtransaction program through a bi-directional communicational link 402.The server 410 of the online financial transaction program includes thecommunication engine S 415, an integration engine 420, and a pluralityof databases, for example a user ID database 425, a financial datadatabase 430 and an unsafe website blacklist database 435, as shown inFIG. 4.

However, the plurality of databases of the server 410 is not limited tothe databases shown in FIG. 4, nor are the databases in FIG. 4exhaustive in any way. The databases shown in FIG. 4 are provided forexemplary purposes only. For instance, additional databases couldinclude a database that stores reward points, a database that stores thetransaction history of the user, or a database that stores a list of thestores that the user has shopped at before.

Whenever a user conducts an action with the GUI Wallet (e.g.dragging-and-dropping a button into a page of a merchant website asshown above in FIG. 2 or FIG. 3, or conducting a financial transactionas further detailed in the description of FIG. 5), the communicationengine W 135, the communication engine S 415, the integration engine420, the plurality of databases (shown in FIGS. 4 as 425, 430 and 435)and the server 410 initiate a procedure for sending and receiving data.This procedure is further detailed in the description of the flowchartin FIG. 7. In general, encrypted data is sent from the communicationengine W 135 over the bidirectional communication link 402 to theInternet connection 405 and then to the communication engine S 415,where the data is decrypted. Example data encryption methods comprisesecure 128-bit encryption or 64-bit encryption methods or Secure SocketsLayer (SSL) encryption methods. After the data is received and decryptedby the communication engine S 415, it is sent to the integration engine420. The integration engine 420 works with the received data and theplurality of databases—here, shown as the user ID database 425, thefinancial data database 430 and unsafe website blacklist database 435—inorder to properly execute transactions with the online financialtransaction program, validate the authenticity of IDs, performerror-checking tasks and execute security checks. Specifically, theintegration engine 420 is a business logic interface (any logic oralgorithm that handles the information exchange between a database andother software components) that takes the information received by thecommunication engine S 415 and looks up, verifies and uses data from theplurality of databases in order to effectively conduct transactions.Data coming from the server 410 of the online financial transactionprogram is sent back to the GUI Wallet in the same manner as describedabove. Namely, data is first encrypted by the communication engine S 415and then sent over the bidirectional communication link 402 over theInternet connection 405 to the communication engine W 135, where it isdecrypted and then used.

Examples of using the GUI Wallet will be provided in order to furtherunderstanding of the plurality of databases in the server 410.

For instance, if the user were to drag-and-drop the f ID button 120 intoa User ID Page 210 of a merchant website as described above for FIG. 2,the communication engine W 135 would then communicate this instruction,in encrypted form, over the bidirectional communication link 402 and theInternet connection 405 to the communication engine S 415. Thecommunication engine S 415 would then decrypt the data instruction andsend it to the integration engine 420. The integration engine 420 wouldthen locate the proper ID information from the user ID database 425 andthen use its logic to place the relevant ID information in the pluralityof ID fields 215, as shown in FIG. 2.

A similar process exists if the user were to drag-and-drop any of theplurality of funding source buttons into a Payment Method Page 310 of amerchant website as described above for FIG. 3. The communication engineW 135 would communicate this instruction over the bidirectionalcommunication link 402 and the Internet connection 405 to thecommunication engine S 415. The communication engine S 415 would thendecrypt the data instruction and send it to the integration engine 420.The integration engine 420 would then locate the proper ID informationfrom the financial data database 430 and then use its logic to place therelevant financial data in any of the plurality of entry fields (e.g.315. 320, 325 or 330) as shown in FIG. 3.

The above described process also enables the alert button 130 of thefirst tab 100 of the GUI Wallet to issue an alarm, as described abovefor FIG. 1. Any time a merchant website is browsed, the server 410 ofthe online financial transaction program is engaged and the integrationengine 420 can readily perform lookups with the plurality of databases.If the user is attempting to make a transaction on a potentially unsafewebsite, the integration engine 420 checks the potentially unsafewebsite against the websites listed in the unsafe website blacklistdatabase 435. If there is a match, then the communication engine S 415sends an encrypted message about this unsafe website over the Internetconnection 405 and the bidirectional communication link 402 to thecommunication engine W 135, where it is then decrypted and then sent tothe alert button 130 for alerting the user, such as lighting-up a GUIfeature or popping up a separate message window.

The above described process also enables message windows to pop up fromeither the first tab 100 or the second tab 500 of the GUI Wallet toinform the user if a transaction was successful (e.g. a money transferor currency conversion) or a message window informing the user of aspecific piece of information (e.g. a specific balance amount afterperforming a balance inquiry), as will be further detailed in thedescription of FIG. 5. Any time a user decides to conduct a financialtransaction with the second tab 500 of the GUI Wallet, the server 410 ofthe online financial transaction program is engaged and the integrationengine 420 can readily perform lookups with the plurality of databases.Once the user has completed a transaction, successfully or not, orperformed a balance inquiry, the communication engine S 415 sends anencrypted message about the status of the transaction (successful orunsuccessful) or the specific balance amount inquired about over theInternet connection 405 and the bidirectional communication link 402 tothe communication engine W 135, where it is then decrypted and thendisplayed as a message window in the GUI Wallet. For instance, a messagewindow could pop up stating that the transaction (e.g. money transfer orcurrency conversion) was successful or unsuccessful, or a message windowcould pop up describing to the user the specific balance of an accountthe user performed a balance inquiry on. The details of this processwill also be described in the descriptions of FIG. 5 and FIG. 7.

FIG. 5 is a diagram of a GUI Wallet with a second tab having a secondplurality of buttons according to another embodiment of the invention.The second tab 500 of the GUI Wallet is shown behind the first tab 100of the GUI Wallet, but the second tab 500 is not limited to thisposition and can be located anywhere with respect to the first tab 100.Furthermore, the number of tabs of the GUI Wallet is not limited tomerely two, and the first tab 100 and second tab 500 are provided onlyfor illustrative purposes. Additional tabs may be added as necessary oras a software engineer sees fit. The second tab 500 includes a pluralityof transaction buttons and like FIG. 1, a GUI representation of thecommunication engine W 135, which is internal to the GUI Wallet softwareapplication but can be represented by any GUI indicator, but is shown inFIG. 5 as a generic icon.

The second tab 500 of the GUI Wallet comprises a plurality oftransaction buttons which can include, for example, a balance checkbutton 505 (“Bal.”), a transfer money button 510 (“Send”), and acurrency conversion button 515 (“Con.”), as shown in FIG. 5. However,the plurality of transaction buttons is not limited to theaforementioned list, and the above list is not exhaustive in any way.For example, other transaction buttons can include a button that acceptspayments or money transfers from another party, a button that can paybills or set-up bill payments, and a button that can perform anyfinancial transaction that is performed with an online financialtransaction program via an Internet browser.

The balance check button 505 is tied to software in the GUI Wallet thathas the user's login information already entered, and that is able toretrieve the balance of a given account belonging to the user that isregistered with the user's online financial transaction program. Forinstance, if the user were to select the balance check button 505, apop-up window with a field querying the user for an account number orother account identifier would appear. After the user enters the accountnumber or other account identifier, the GUI Wallet retrieves and returnsto the user the balance of the particular account associated with theprovided account number or identifier, usually by means of anothermessage window. The balance check button 505 also works with thecommunication engine method described above for FIG. 4 and looks up thebalance of a particular user account in the plurality of databases, forexample the financial data database 430 shown in FIG. 4, and sends thisdata back to the GUI Wallet from the server in order to have the GUIWallet display to the user the proper balance of a selected account, forinstance in a separate message window.

The transfer money button 510 is tied to software in the GUI Wallet thathas the user's login information already entered, and that is able toaccess the financial data of a user's account and actually transfermoney from a user's account to another account or to pay for purchases.For instance, if the user were to select the transfer money button 510,a pop-up window with a field querying the user for a transferee ordestination account number and a transfer amount would appear. After theuser enters the transferee/destination number and the transfer amount,the GUI Wallet executes the money transfer and then informs the userabout whether the money transfer was successful or not, usually by meansof another message window or by using the alert window 130 of the firsttab 100 of the GUI Wallet. The transfer money button 510 also works withthe communication engine method described above for FIG. 4 and is ableto work with the plurality of databases in the server 410 and canexecute financial transactions (e.g. a money transfer) over the server410 just as if the user were performing transactions through his or heronline financial transaction program website. A data message describingwhether the money transfer was successful or not is also sent from theserver back to the GUI Wallet in order to have the GUI Wallet display tothe user whether or not the money transfer was successful in a separatemessage window.

The currency conversion button 515 is tied to software in the GUI Walletthat has the user's login information already entered, and that is ableto access the financial data of a user's account and actually convertfunds from a user's account from one type of currency to another type ofcurrency. For instance, if the user were to select the currencyconversion button 515, a pop-up window with a field querying the userfor a beginning currency type, a beginning currency amount, and an endcurrency type would appear. After the user enters the beginning currencytype, a beginning currency amount, and an end currency type, the GUIWallet executes the currency conversion and then informs the user aboutwhether the currency conversion was successful or not, usually by meansof another message window or by using the alert button 130 of the firsttab 100 of the GUI Wallet. The currency conversion button 515 also workswith the communication engine method described above for FIG. 4 and isable to work with the plurality of databases and can execute financialtransactions (e.g. currency conversion) over the server 410 just as ifthe user were performing financial transactions through his or heronline financial transaction program website. A data message describingwhether the currency conversion was successful or not is also sent fromthe server back to the GUI Wallet in order to have the GUI Walletdisplay to the user whether or not the currency conversion wassuccessful in a separate message window.

Again, it is to be reiterated that the plurality of transaction buttonsis not limited to the above three described buttons and can comprisebuttons that allow a user to perform any other financial transactionthat the user would have been able to perform on the user's financialtransaction program website with an Internet browser. For instance,other transaction buttons can include a button that accepts payments ormoney transfers from another party (which may be more applicable if theuser was a merchant), and a button that can pay bills or set-up billpayments (on a periodic or non-periodic basis). The use of the pluralityof transaction buttons on the second tab 500 of the GUI Wallet isrobust, simple and convenient because it allows a user to conductfinancial transactions with his or her online financial transactionprogram seamlessly and securely, independent of an Internet browser.

FIG. 6 is a flowchart showing the steps a user takes in using a GUIWallet to conduct transactions according to another embodiment of theinvention. Method 600 is the process in which the user drags-and-drops afunding source or ID button or pushes a transaction button of the GUIWallet in order to conduct a transaction with the GUI Wallet. In step605, the user starts the process and opens up the GUI Walletapplication. In step 610, the user supplies relevant log-in data tolog-in to the server 410 of the online financial transaction program,shown in FIG. 4. This is usually the username and password a user usesto log-in to his or her account on a central online financialtransaction program website. If the user cannot log-in, the user isbrought back to step 605, the start of the process. If the usersuccessfully logs in, then in step 615, the user's status and financialinformation is checked and verified by looking up the data in thefinancial data database 430 of the server 410 of the online financialtransaction program. Then, the GUI Wallet appears on a user's screen,and in step 625, the user is presented with a plurality of buttons, suchas the plurality of funding source buttons as well as the ID and alertbuttons described in FIG. 1 and the plurality of transaction buttonsdescribed in FIG. 5. If the user wishes to use the drag-and-dropfunctionality of the plurality of funding source buttons, then the userwill go to a page of a merchant website in order to make a purchase.Once the user is on the merchant website, the server 410 of the onlinefinancial transaction program is engaged, and the server 410 works withthe integration engine 420 to check, in step 630, if the merchantwebsite the user is browsing belongs to the blacklist of unsafe websitesstored in the unsafe website blacklist database 435.

If the merchant website is unsafe, then in step 620, a warning isdisplayed either in a separate message window or on the alert button 130of the first tab 100 of the GUI Wallet. If the merchant website is safe,then the user can continue to choose one of the plurality of fundingsource buttons to drag-and-drop into a merchant website, or the user canchoose to conduct a financial transaction (e.g. transferring money,converting currencies, checking balances) that is independent of amerchant website, in step 635. In step 640, the GUI Wallet and theserver 410 communicate in the process described above for FIG. 4 and themethod that will be detailed in FIG. 7 in order to conduct thetransaction that the user has selected. In step 645, the server 410determines whether or not the transaction was successful. If thetransaction was not successful, a message window is displayed from theGUI Wallet that describes the transaction failure and the reason forfailure in step 655. If, on the other hand, the transaction issuccessful, a message window is displayed from the GUI Wallet thatdescribes the success of the transaction and the reason why thetransaction was a success in step 650. Then, in step 660, the user hasthe choice of returning to step 625 to select another button from theGUI Wallet, or deciding to end method 600. If the user decides to endthe method 600, the user starts all over from step 605 and logs in againin step 610.

FIG. 7 is a flowchart showing the steps of how the communication engineof the GUI Wallet and the communication engine of the server send andreceive data, according to another embodiment of the invention. Method700 is the process in which communication engine W 135 and communicationengine S 415 encrypt, send and receive data to one another, as describedabove for FIG. 4. The method starts in step 705, and in step 710, themethod determines whether the processing starts from the GUI Walletside, or starts from the server side. Basically, the processing startsfrom the GUI Wallet side if the user is using the first tab 100 of theGUI Wallet and plans to drag-and-drop a button from the plurality ofbuttons available (e.g. the plurality of funding source buttons or an IDbutton) into a page of a merchant website. On the other hand, theprocessing starts from the server side if the user decides to use atransaction button from the plurality of transaction buttons on thesecond tab 500 of the GUI Wallet. The processing also starts from theserver side if the user is simply browsing a merchant website and themerchant website is unsafe, thereby triggering the alarm button 130. Ifthe processing starts from the server side, then the method proceeds tostep 735. If the processing starts from the GUI Wallet side, then themethod proceeds to step 715, where the communication engine W 135encrypts a data message instruction, usually by using a secure 64-bit or128-bit encryption method or a SSL encryption method. A data messageinstruction usually comprises the software instructions for having theuser drag-and-drop a button from the first tab 100 of the GUI Walletinto a page of the merchant website.

Then, in step 720, the encrypted data message instruction is sent overthe bidirectional communication link 402 and the Internet connection 405and crosses into the server side to reach step 725. In step 725,communication engine S 415 receives and decrypts the data messageinstruction. The communication engine S 415 then sends the decrypteddata message instruction to the integration engine 420. In step 735, theserver 410 is engaged because the user is browsing a page of themerchant website, and the server 410 is engaged whenever the user isperforming Internet browsing. In step 735, the integration engine 420works with the plurality of databases (shown in FIG. 4 as elements 425,430 and 435 for exemplary purposes only) and the server 410, as well asany incoming data message instructions sent by the communication engineS 415 to perform any functions. These functions can comprise populatingempty fields of a page on a merchant website with user ID data orpayment method data, conducting financial transactions with the onlinefinancial transaction program (e.g. money transfers, currencyconversions, paying for purchases), validating the authenticity of userlogin IDs, performing error-checking tasks and executing security checkson potentially unsafe websites. Then, after step 735, where theintegration engine 420 works with the databases and the server 410 toperform any tasks, the method determines whether a message has to bedisplayed by the GUI Wallet in order to alert the user on the status ofa certain transaction. In the case of a simple drag-and-drop of afunding source or ID button from the first tab 100 of the GUI Wallet,the user does not need to be notified with a message window from the GUIWallet because the user can immediately see the empty fields of amerchant website page being populated with the user's data. In such acase where a message does not need to be displayed to the user, themethod then proceeds to step 745 and goes back to the start, step 705,and then the above mentioned process is repeated.

However, if it is necessary to have a message displayed by the GUIWallet, and a “Yes” is answered to the inquiry posed in step 740, thenthe method proceeds to step 750. In step 750, the method is still on theserver side, therefore communication engine S 415 encrypts a datamessage instruction, usually by using a secure 64-bit or 128-bitencryption method or a SSL encryption method. The data messageinstruction is usually the software instructions for having the userdrag-and-drop a button from the first tab 100 of the GUI Wallet into apage of the merchant website. The data message instruction here usuallycomprises the software instructions for displaying a status message tothe user by using the GUI Wallet to display a separate message window orhaving the alert button 130 light up or animate. This data messageinstruction is being sent to the GUI Wallet side from the server sidebecause it is ultimately the GUI Wallet that will be displaying themessage for the user to view.

In step 755, the encrypted data message is sent by the communicationengine S 415 over the bidirectional communication link 402 and theInternet connection 405 over to the GUI Wallet side, where it isreceived by communication engine W 135 and decrypted in step 760. Then,the GUI Wallet takes the software instruction from the decrypted datamessage instruction and then displays a message in a separate messagewindow from the GUI Wallet or uses the alarm button 130 of the GUIWallet to display the warning or message. After the message isdisplayed, the method proceeds to step 770 and goes back to the start,or step 705.

The message the user will view usually comprises either a successful orunsuccessful completion of a financial transaction (e.g. whether moneywas successfully transferred, or received, or whether currency has beensuccessfully converted), the balance of a certain account the user hasperformed a balance inquiry on, or whether the user has reached anunsafe site and informing the user that he or she is currently browsingan unsafe site.

Even though the GUI Wallet comprises a first tab 100 and a second tab500 and each tab comprises a plurality of different buttons, asdescribed above, the buttons detailed above associated with the firsttab 100 do not necessarily have to be placed on the first tab 100 andthe buttons detailed above associated with the second tab 500 do nothave to be placed on the second tab 500. In other words, the buttons canbe placed anywhere with respect to the GUI Wallet. In addition, the GUIWallet is not limited to just a first tab 100 and a second tab 500 andcan comprise any number of tabs, and the buttons can be placed on any ofthese tabs.

The GUI Wallet can also be customized in any way that a user, aconnected system, control logic or another entity sees fit. In otherwords, buttons on any of the tabs can be moved to other tabs, new tabscan be created, tabs can be removed or modified, existing buttons can beremoved or modified, and new buttons can be added. The customizabilityof the GUI Wallet is intrinsic to the GUI properties of the GUI Walletand is not limited to the above examples. The GUI Wallet can also becustomized to optimize the user experience.

The GUI Wallet and any of the tabs of the GUI Wallet can be written in alanguage comprising Java, XML, C++ or C, and can also be written in alanguage with a flexible and user-customizable API where a user can addon features easily without having to understand the intricacies of aparticular code. The plurality of databases in the server 410 can bewritten in a language comprising SQL, Perl, or another databaselanguage. The communication engine W 135, the communication engine S415, and the integration engine 420 can be written in a languagecomprising C, C++ or Java.

Advantages of the present invention include granting a user the abilityto securely and seamlessly conduct transactions with his or her onlinefinancial transaction program by means of a computer or a wirelesshandheld device without having to depend on an Internet browser. Aconvenient drag-and-drop functionality also enables the user to simplydrag-and-drop pre-stored settings and information into empty fields of apage of a merchant website without having to remember account numbers orother ID data or open up a separate page in another Internet browser.

The above-described embodiments of the present invention are merelymeant to be illustrative and not limiting. It will thus be obvious tothose skilled in the art that various changes and modifications may bemade without departing from this invention in its broader aspects.Therefore, the appended claims encompass all such changes andmodifications as fall within the true spirit and scope of thisinvention.

We claim:
 1. A transaction information provisioning system, comprising:a wireless user device; and a communication engine that is located inthe wireless user device and that: receives login information; sends thelogin information over a network; and receives a plurality of fundingsource information through the network in response to sending the logininformation, wherein the plurality of funding source information isassociated with a plurality of different funding sources; and whereinthe wireless user device renders a graphical user interface (GUI) walletfor display that includes a plurality of funding source elements thatare each associated with a respective one of the plurality of differentfunding sources and that are each selectable to automatically retrieverespective funding source information for the respective funding sourceassociated with that funding source element and automatically populate afunding source field in a merchant checkout system with the respectivefunding source information.
 2. The transaction information provisioningsystem of claim 1, wherein the GUI wallet includes a first fundingsource element that is associated with a first funding source of theplurality of different funding sources and that is selectable toautomatically retrieve first funding source information for the firstfunding source and automatically populate a first funding source fieldin a first merchant checkout system with the first funding sourceinformation, and wherein the GUI wallet includes a second funding sourceelement that is associated with a second funding source of the pluralityof different funding sources that is different than the first fundingsource and that is selectable to automatically retrieve second fundingsource information for the second funding source and automaticallypopulate a second funding source field in a second merchant checkoutsystem that is different than the first merchant checkout system withthe second funding source information.
 3. The transaction informationprovisioning system of claim 1, wherein the plurality of funding sourcesinclude a credit funding source and a debit funding source.
 4. Thetransaction information provisioning system of claim 1, furthercomprising: the communication engine that receives a plurality ofaddress information through the network in response to sending the logininformation, wherein the plurality of address information is associatedwith a plurality of different addresses; and wherein the wireless userdevice renders the GUI wallet for display that includes a plurality ofaddress elements that are each associated with a respective one of theplurality of different addresses and that are each selectable toautomatically retrieve respective address information for the respectiveaddress associated with that address element and automatically populatean address field in the merchant checkout system with the respectiveaddress information.
 5. The transaction information provisioning systemof claim 4, wherein the GUI wallet includes a first address element thatis associated with a first address of the plurality of differentaddresses and that is selectable to automatically retrieve first addressinformation for the first address and automatically populate a firstaddress field in a first merchant checkout system with the first addressinformation, and wherein the GUI wallet includes a second addresselement that is associated with a second address of the plurality ofdifferent addresses that is different than the first address and that isselectable to automatically retrieve second address information for thesecond address and automatically populate a second address field in asecond merchant checkout system that is different than the firstmerchant checkout system with the second address information.
 6. Thetransaction information provisioning system of claim 1, furthercomprising: the communication engine that receives a plurality ofdiscount information through the network in response to sending thelogin information, wherein the plurality of discount information isassociated with a plurality of different discounts; and wherein thewireless user device renders the GUI wallet for display that includes aplurality of discount elements that are each associated with arespective one of the plurality of different discounts and that are eachselectable to automatically retrieve respective discount information forthe respective discount associated with that discount element andautomatically populate a discount field in the merchant checkout systemwith the respective discount information.
 7. The transaction informationprovisioning system of claim 7, wherein the GUI wallet includes a firstdiscount element that is associated with a first discount of theplurality of different discounts and that is selectable to automaticallyretrieve first discount information for the first discount andautomatically populate a first discount field in a first merchantcheckout system with the first discount information, and wherein the GUIwallet includes a second discount element that is associated with asecond discount of the plurality of different discounts that isdifferent than the first discount and that is selectable toautomatically retrieve second discount information for the seconddiscount and automatically populate a second discount field in a secondmerchant checkout system that is different than the first merchantcheckout system with the second discount information.
 8. A method forproviding transaction information, comprising: receiving, by acommunication engine that is located in a user device, logininformation; sending, by the communication engine, the login informationover a network; receiving, by the communication engine, a plurality ofaddress information through the network in response to sending the logininformation, wherein the plurality of address information is associatedwith a plurality of different addresses; and rendering, by the userdevice, a graphical user interface (GUI) wallet for display thatincludes a plurality of address elements that are each associated with arespective one of the plurality of different addresses, wherein aselection of one of the plurality of address elements results in anautomatic retrieval of respective address information for the respectiveaddress associated with that address element and an automatic populatingof an address field in a merchant checkout system with the respectiveaddress information.
 9. The method of claim 8, wherein: a selection of afirst address element of the plurality of address elements results in anautomatic retrieval of first address information for a first addressassociated with the first address element and an automatic populating ofa first address field in a first merchant checkout system with the firstaddress information; and a selection of a second address element of theplurality of address elements results in an automatic retrieval ofsecond address information for a second address that is associated withthe second address element and that is different than the first address,and an automatic populating of a second address field in a secondmerchant checkout system that is different than the first merchantcheckout system with the second address information.
 10. The method ofclaim 8, wherein the plurality of addresses include a billing address ofthe user and a shipping address of the user.
 11. The method of claim 8,further comprising: receiving, by the communication engine, a pluralityof funding source information through the network in response to sendingthe login information, wherein the plurality of funding sourceinformation is associated with a plurality of different funding sources;and rendering, by the user device, the GUI wallet for display thatincludes a plurality of funding source elements that are each associatedwith a respective one of the plurality of funding sources, wherein aselection of one of the plurality of funding source elements results inan automatic retrieval of respective funding source information for therespective funding source associated with that funding source elementand an automatic populating of a funding source field in a merchantcheckout system with the respective funding source information.
 12. Themethod of claim 11, wherein: a selection of a first funding sourceelement of the plurality of funding source elements results in anautomatic retrieval of first funding source information for a firstfunding source associated with the first funding source element and anautomatic populating of a first funding source field in a first merchantcheckout system with the first funding source information; and aselection of a second funding source element of the plurality of fundingsource elements results in an automatic retrieval of second fundingsource information for a second funding source that is associated withthe second funding source element and that is different than the firstfunding source, and an automatic populating of a second funding sourcefield in a second merchant checkout system that is different than thefirst merchant checkout system with the second funding sourceinformation.
 13. The method of claim 8, further comprising: receiving,by the communication engine, a plurality of discount information throughthe network in response to sending the login information, wherein theplurality of discount information is associated with a plurality ofdifferent discounts; and rendering, by the user device, the GUI walletfor display that includes a plurality of discount elements that are eachassociated with a respective one of the plurality of discounts, whereina selection of one of the plurality of discount elements results in anautomatic retrieval of respective discount information for therespective discount associated with that discount element and anautomatic populating of a discount field in a merchant checkout systemwith the respective discount information.
 14. The method of claim 13,wherein: a selection of a first discount element of the plurality ofdiscount elements results in an automatic retrieval of first discountinformation for a first discount associated with the first discountelement and an automatic populating of a first discount field in a firstmerchant checkout system with the first discount information; and aselection of a second discount element of the plurality of discountelements results in an automatic retrieval of second discountinformation for a second discount that is associated with the seconddiscount element and that is different than the first discount, and anautomatic populating of a second discount field in a second merchantcheckout system that is different than the first merchant checkoutsystem with the second discount information.
 15. A non-transitory,machine-readable medium comprising a plurality of machine-readableinstructions that, when executed by one or more processors, areconfigured to cause the one or more processors to perform a methodcomprising: providing a communication engine that: receives logininformation; sends the login information over a network; and receives aplurality of discount information through the network in response tosending the login information, wherein the plurality of discountinformation is associated with a plurality of different discounts; andrendering a graphical user interface (GUI) wallet for display thatincludes a plurality of discount elements that are each associated witha respective one of the plurality of different discounts, wherein aselection of one of the plurality of discount elements results in anautomatic retrieval of respective discount information for therespective discount associated with that discount element and anautomatic provision of the respective discount information to anelectronic transaction system to satisfy a discount information request.16. The machine-readable medium of claim 15, wherein: a selection of afirst discount element of the plurality of discount elements results inan automatic retrieval of first discount information for a firstdiscount and an automatic providing of the first discount information toa first electronic transaction system to satisfy a first discountinformation request; and a selection of a second discount element of theplurality of discount elements results in an automatic retrieval ofsecond discount information for a second discount that is different thanthe first discount and an automatic provision of the second discountinformation to a second electronic transaction system that is differentthan the first electronic transaction system to satisfy a seconddiscount information request.
 17. The machine-readable medium of claim15, wherein the plurality of machine-readable instructions areconfigured to cause the one or more processors to perform the methodfurther comprising: providing the communication engine that: receives aplurality of funding source information through the network in responseto sending the login information, wherein the plurality of fundingsource information is associated with a plurality of different fundingsources; and rendering the GUI wallet for display that includes aplurality of funding source elements that are each associated with arespective one of the plurality of different funding sources, wherein aselection of one of the plurality of funding source elements results inan automatic retrieval of respective funding source information for therespective funding source associated with that funding source elementand an automatic provision of the respective funding source informationto an electronic transaction system to satisfy a funding sourceinformation request.
 18. The machine-readable medium of claim 17,wherein: a selection of a first funding source element of the pluralityof funding source elements results in an automatic retrieval of firstfunding source information for a first funding source and an automaticprovision of the first funding source information to a first electronictransaction system to satisfy a first funding source informationrequest; and a selection of a second funding source element of theplurality of funding source elements results in an automatic retrievalof second funding source information for a second funding source that isdifferent than the first funding source and an automatic provision ofthe second funding source information to a second electronic transactionsystem that is different than the first electronic transaction system tosatisfy a second funding source information request.
 19. Themachine-readable medium of claim 15, wherein the plurality ofmachine-readable instructions are configured to cause the one or moreprocessors to perform the method further comprising: providing thecommunication engine that: receives a plurality of address informationthrough the network in response to sending the login information,wherein the plurality of address information is associated with aplurality of different addresses; and rendering the GUI wallet fordisplay that includes a plurality of address elements that are eachassociated with a respective one of the plurality of differentaddresses, wherein a selection of one of the plurality of addresselements results in an automatic retrieval of respective addressinformation for the respective address associated with that addresselement and an automatic provision of the respective address informationto an electronic transaction system to satisfy an address informationrequest.
 20. The machine-readable medium of claim 19, wherein: aselection of a first address element of the plurality of addresselements results in an automatic retrieval of first address informationfor a first address and an automatic provision of the first addressinformation to a first electronic transaction system to satisfy a firstaddress information request; and a selection of a second address elementof the plurality of address elements results in an automatic retrievalof second address information for a second address that is differentthan the first address and an automatic provision of the second addressinformation to a second electronic transaction system that is differentthan the first electronic transaction system to satisfy a second addressinformation request.